Isn't the whole point of ArrayObject: "This class allows objects to work as arrays."? (what may not have been the best idea, though)

I have no clue what the point is, tbh. I really don't understand when that would be useful. In any case, this allows to circumvent both type and readonly checks (https://3v4l.org/KOWT9), which can both violate assumptions. Types are obvious. Readonly can break internal enum name checks when the name of internal enums is changed.

My point was more that instead of disallowing objects in ArrayObject, maybe we should deprecate that class instead. And until it is removed, document its limitations.

And frankly, not only ArrayObject but also some other parts of SPL look pretty much immature to me.

Indeed. Unfortunately, there's quite a bit of use of ArrayObject in the wild. For now, I'll check if it's possible to uphold property types and readonly for internal classes, where the actual assertions can occur. I don't object to deprecating ArrayObject in the future, but I also don't care if it no longer causes unsoundness.

@cmb69 Having looked at this more, you were right. This class is pure madness. Basically none of the operations behave like they should. Some of the issues:

• Types are not respected (as mentioned). This goes for read+r and read+w.
• Readonly is not respected (as mentioned). This goes for write and unset.
• Foreach over class with readonly is broken. There's already some hacky code trying to fix it, but it doesn't work for nested ArrayObject instances, which is the case for getIterator(). There are also some reference tracking assertions being raised.
• References are broken. Most writes ignore and thus overwrite references.
• The code is absolute carnage. It handles extremely weird edge cases (nested ArrayObject, ArrayObject with self as the object, extended ArrayObject), which make it hard to anticipate unwanted side-effects when tweaking the logic.

IMO, we should try to understand the use-cases online, see whether they have good alternatives, and then deprecate this class.

Thanks for having a closer look at the implementation!

I would presume that ArrayObject is often just used for convenience, to not having to implement the interfaces "manually". Some closer investigation might be in order, but maybe just asking on the list can shed some light on how deprecating ArrayObject would be received by the community.

Agreed with @cmb69 that there should be more warnings and documentation of the limitations of ArrayAccess and any other parts of the SPL that aren't fully baked, otherwise the number of projects using them is just going to grow until they are formally deprecated.

Note that ArrayIterator is also closely tied to the implementation of ArrayObject, but I agree that we should kill this class with fire as it violates every possible invariant in existence.

@cmb69 @nielsdos @bwoebi Given recent discussions on ArrayObject issues, is this reasonable first step? ArrayObject allows to modify the readonly name and value properties. This is not only highly confusing (e.g. the value will diverge from the from/tryFrom map) but also breaking for internal enums, because of code like this:

I am fine with disallowing enums, as those are rather a recent addition and unlikely to have been used in conjunction with ArrayObject.

I decided to only merge this for master. Woe is you if you're relying on this behavior.